Cookbook Contents | Next >

Changes in the Apache Shindig project that involve the unit test gadget outlined on this page have made this page obsolete. If you visited this page prior to July 17, 2013 at 1am GMT you will need to delete the existing Widget that you imported and re-import based on the updated attachment.

Overview

Once the OpenSocial Component has been installed and configured, an administrator has many options for verifying that the environment is working properly. This article provides one simple verification option that administrators can use. Please review the gadget data flow and Widget approval process articles, especially the "Importing a Widget into the Widget Catalog" section of the latter, before continuing.

An administrator planning to integrate with IBM Connections 4 should perform this verification first. IBM Connections 4 integration requires OAuth, which adds an extra level of complexity to this simple verification.

Introducing the Unit Test Widget

For the purposes of this verification, a unit test gadget from the Apache Shindig project will be used. The gadget being used is the Test Gadget and Container Domain Configuration gadget that resides in the Apache Shindig source control system. This gadget will help to verify two things: first, it will verify that OpenSocial gadgets are able to render in Notes and iNotes; second, it will run unit tests and report on domain configuration, such as locked domains. For the purposes of this article, the priority will be on the former, but the latter can also be useful when sanity checking the configuration of one's environment.

When the gadget runs it will use Jasmine to run 4 unit tests and report the results. The tests that run are as follows:

1. The gadget is rendering over https
2. The gadget is rendering on a locked domain
3. The gadget cannot access the parent window
4. The gadget cannot access the parent window by lowering its domain

These tests correlate to the configuration performed in earlier sections of this cookbook:

1. The first test checks to see if the iframe in which the gadget is rendering is using HTTPS. For iNotes, this directly correlates to the "Gadget iframe Scheme" section of Server-centric settings. For Notes, this test will always fail, as gadgets render on localhost.
2. The second test checks to see if the iframe in which the gadget is rendering is on a locked domain. This directly correlates to the "Locked Domains" section of Server-centric settings. For Notes, this will always pass, as locked domains are handled locally and don't rely on the server configuration.
3. The third and fourth tests check to see if the iframe in which the gadget is rendering is not only on a locked domain but on a separate top-level domain from the container, i.e., Notes or iNotes. For Notes, this will always pass, as locked domains are handled locally and don't rely on the server configuration.

The following screenshot shows the gadget running in the Notes client.

Importing the Unit Test Widget

Getting the unit test widget up and running in the Notes and iNotes clients has been made easy by leveraging the new "Import" functionality in the Widget Catalog. Use the attached "UnitTestGadget.zip" and the instructions in the "Importing a Widget into the Widget Catalog" in the Widget approval process article to import the unit test gadget into the widget catalog.

Running the Unit Test Widget

The unit test widget, once imported and approved, can be easily run in Notes or iNotes. Simply browse the Widget catalog, drag-and-drop to install the Widget, then double-click on the Widget to open it. The widget will load in the client and report the results as exemplified above.

Keep in mind that the success of the rendering the unit test widget will rely on the processes outlined in gadget data flow, e.g., the local widget catalog replica in Notes will need to be up-to-date and the data in the credential store will have to have been updated in memory on the Domino Server with Shindig.

Cookbook Contents | Next >